|
l
|
Network Address Translation (NAT) is a licensed in-line service feature requiring the following licenses:
|
l
|
[ 600-00-7805 ] NAT/PAT With DPI
|
|
l
|
Any other in-line service counting license (Enhanced Charging Service, Stateful Firewall, Content Filtering, etc.). For more information, please contact your local sales representative.
|
For information on license requirements for customer-specific NAT features, please contact your local sales/service representative.
IMPORTANT: For information on installing licenses, see the Managing License Keys chapter of the System Administration and Configuration Guide.|
l
|
|
l
|
RFC 4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status; July 2007
|
|
l
|
RFC draft-nishitani-cgn-00.txt: Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP; July 2, 2008
|
NAT translates non-routable private IP address(es) to routable public IP address(es) from a pool of public IP addresses that have been designated for NAT. This enables to conserve on the number of public IP addresses required to communicate with external networks, and ensures security as the IP address scheme for the internal network is masked from external hosts, and each outgoing and incoming packet goes through the translation process.
NAT works by inspecting both incoming and outgoing IP datagrams and, as needed, modifying the source IP address and port number in the IP header to reflect the configured NAT address mapping for outgoing datagrams. The reverse NAT translation is applied to incoming datagrams.
NAT can be used to perform address translation for simple IP and mobile IP. NAT can be selectively applied/denied to different flows (5-tuple connections) originating from subscribers based on the flows' L3/L4 characteristics—Source-IP, Source-Port, Destination-IP, Destination-Port, and Protocol.
IMPORTANT: To get NATed, the private IP addresses assigned to subscribers must be from the following ranges:- Class A 10.0.0.0 – 10.255.255.255
- Class B 172.16.0.0 – 172.31.255.255
- Class C 192.168.0.0 – 192.168.255.255
|
l
|
One-to-One: In one-to-one NAT each private IP address is mapped to a unique public NAT IP address. The private source ports do not change.
|
When a private IP address (IP1:port1) is mapped to a public IP address (IP2:port1), any packets from IP1:port1 will be sent as though via IP2:port1. The external host can only send packets to IP2:port1, which are translated to IP1:port1. The NAT port number will be the same as the source private port.
|
l
|
Many-to-One: In many-to-one NAT, multiple private IP addresses are mapped to a single public NAT IP address. In order to distinguish between different subscribers and different connections originating from same subscriber, internal private L4 source ports are translated to pre-assigned L4 NAT ports. Ports are allocated in chunks such that each private IP address is reserved a set of ports for future use. This is also known as Network Address Port Translation (NAPT).
|
Once a flow is marked to use a specific NAT IP address the same NAT IP address is used for all packets originating on that flow. The NAT IP address is released only when all flows and subscribers associated it are released.
When all NAT IP addresses are in use, and a subscriber with a private IP address fails to get a NAT IP address for a specific flow, that specific flow will not be allowed and will fail.
All downlink—inbound from external networks—IP packets that do not match one of the existing NAT bindings are discarded by the system.
A NAT realm is a pool of unique public IP addresses available for translation from private source IP addresses. IP addresses in a NAT realm are contiguous, and assignable as a subnet or a range that constitutes less than an entire subnet. IP addresses configured in NAT realms within a context must not overlap. At any time, within a context, a NAT IP address must be configured in any one NAT realm. IP addresses can be added to a NAT realm as a range of IP addresses.
IMPORTANT: The minimum number of public IP addresses that must be allocated to each NAT realm must be greater than or equal to the number of Session Managers (SessMgrs) available on the system. This differs on the ST16 and ST40 platforms. On the ST16 platform, it is >= 230 public IP addresses. This can be met by a single Class C. Since a SessMgr does not communicate with other SessMgrs to know what ports have been allocated or free, each SessMgr has its own sub-pool of ports to allocate from.
On the ST40 platform, it is >= 84 public IP addresses. This can be met by a range of 84 host addresses from a single Class C. The remaining space from the Class C can be used for other allocations.
Each address has available its port range ~64K ports.
Up to 2000 unique “IP pools + NAT IP realms” can be configured per context. A subscriber can be associated with a maximum of three different NAT IP realms. This way a subscriber can have NATed flows on three different NAT IP addresses at the same time.
Allocation of NAT IP addresses in NAT realms to subscriber traffic is based on the L3/L4 characteristics—IP addresses, ports, and protocol—of the subscriber flows. It is possible to configure the system to perform or not perform NAT based on one or more L3/L4 parameters. This feature is also known as Target-based NAT. For more information, see the Target-based NAT Configuration section.
NAT realms have the following configurable parameters. These parameters are applicable to all IP addresses in a NAT realm.
|
l
|
NAT IP Address Allocation Mode: Specifies when to allocate a NAT IP address to a subscriber; either at call setup or during data flow based on the allocation mode.
|
|
l
|
Not-on-demand Allocation Mode: This is the default mode. In this mode, the NAT IP address is allocated to the subscriber at call setup. If there are three NAT realms (maximum allowed) configured in the subscriber’s Firewall-and-NAT policy, the subscriber is allocated three NAT IP addresses, one from each realm.
|
|
l
|
On-demand Allocation Mode: In this mode NAT resources are assigned and allocated dynamically based on subscriber flows. The NAT IP address is allocated to the subscriber when the data traffic flows in and not at call setup.
|
In case of on-demand realms, since the NAT IP address is not allocated to the subscriber at call setup, the subscriber may not have a NAT IP address allocated when the first packet is received. Until the successful allocation of a NAT IP address, based on the configuration, the packets can either be buffered or dropped. Once a free NAT IP address is available, it is allocated to the subscriber to be used for flows matching the realm.
|
l
|
NAT Binding Timer: Specifies the timeout period, in seconds, to deallocate NAT resources that were allocated to subscriber flows. The timer starts counting down when subscriber flows stop, and on expiry the NAT resources are deallocated to be available for other subscriber flows.
|
|
l
|
In one-to-one allocation, for a given NAT IP address, the NAT Binding Timer starts counting down when there are no active flows using that NAT IP address. When the NAT Binding Timer expires, the NAT IP address gets deallocated.
|
|
l
|
In many-to-one allocation, wherein subscribers are allocated port-chunks rather than individual ports, as long as a port-chunk is allocated to a subscriber, all ports from that port-chunk are reserved for that subscriber. When all flows using ports from that port-chunk get timed out/cleared, the NAT Binding Timer starts counting down. If any new flows come up before the NAT Binding Timer expires, ports are once again allocated from that port-chunk, and the NAT Binding Timer gets cancelled. As long as there are active flows using the port-chunk it cannot be deallocated. But, if no new flows come and the NAT Binding Timer expires, the port-chunk gets deallocated. In the case of on-demand NAT, if it is the last port-chunk for the NAT IP address, on NAT Binding Timer expiry, the NAT IP address gets deallocated along with the last port-chunk.
|
|
l
|
Maximum Users per NAT IP Address: Applicable only to many-to-one NAT realms. Specifies the maximum number of subscribers sharing one NAT IP address. A maximum of 2016 subscribers can be configured per NAT IP address.
|
|
l
|
Port Chunk Size: Applicable only to many-to-one NAT realms. Specifies the block size of contiguous ports to be assigned to a many-to-one NAT realm subscriber. This number has to be divisible by 32 up to a maximum of 32,256.
|
|
l
|
Maximum Port-chunks per User: Applicable only to many-to-one NAT realms. Specifies the maximum number of port-chunks allowed for an individual subscriber from the same NAT IP address. This will limit subscribers from dominating all the available ports in a many-to-one NAT IP. A maximum of 2016 port-chunks can be configured per subscriber.
|
Consider a case where a single TCP flow is active in a port-chunk. When this connection gets cleared, the TCP NAT port goes to Time Wait state. Since it is the last flow of the port-chunk, the NAT Binding Timer also gets started. Assume NAT Binding Timer >= TCP 2MSL Timer. Once the 2MSL Timer expires, the TCP port would go to Free state. However, the NAT Binding Timer keeps running. On NAT Binding Timer expiry, the port-chunk is deallocated. If this was the last port-chunk for that subscriber, the NAT IP address is also deallocated along with this port-chunk.
In case NAT Binding Timer < TCP 2MSL Timer, at NAT Binding Timer expiry, the TCP port is forcefully moved to Free state from Time Wait state and the port-chunk deallocated.
|
l
|
Port Chunk Thresholds: Applicable only to many-to-one NAT realms. Specifies threshold in terms of percentage of allocated port-chunks against total port-chunks available. Once the threshold is reached, new subscribers will not be allocated the same NAT IP address.
|
|
l
|
AAA Binding Update Message Required: Applicable only to one-to-one NAT realms. Enables AAA binding messages for one-to-one NAT realms. This is not supported for many-to-one NAT realms.
|
|
l
|
Alert Thresholds: Threshold limits can be specified to trigger alarms for the NAT pools for pool-used, pool-free, pool-hold, and pool-release cases.
|
|
l
|
SRP-Activate: Applicable to both one-to-one and many-to-one NAT realms. When configured, the NAT IP realm will become usable only when the SRP state is active.
|
Starent Networks’ implementation of NAPT is Endpoint-independent Mapping, wherein NAT reuses the same NAT source port mapping for subsequent packets sent from the same private IP address and port, and with the same protocol to any public destination host IP address and port.
That is, all flows coming from the subscriber for the current session with the same protocol and same source IP address and source port (X:x) would get the same NAT IP address and NAT port (X:x) irrespective of the destination IP address and port. NAT will not allow any inbound packets to the NAT IP address and NAT port (X:x) from an external host IP address and host port (Y:y), unless the internal host (MS) had previously sent a packet of the same protocol type to that external IP address and Port (Y:y). However, this behavior changes if NAT ALG is enabled. The ALG creates pin holes / dynamic routes in the NAT and allows downlink packets that match the pin holes / dynamic routes towards the internal host (MS) given that there was already a parent connection from MS towards the external host.
The advantage of endpoint-independent mapping is that applications are unaffected by NAT translations.
Inbound connection to the NAT IP address can be allowed in one-to-one realms based on configuration.
|
l
|
Maximum Users per NAT IP Address: The maximum number of subscribers sharing a NAT IP address. Once the number of active subscribers using a NAT IP address reaches this limit, that NAT IP address cannot be allocated to new subscribers.
|
|
l
|
Port-chunk Thresholds: The threshold is configured in percentage of total number of port-chunks. If the number of port-chunks already allocated from a given NAT IP address is less than the configured threshold limit of port-chunks, then the NAT IP address can be chosen for a new subscriber provided the “Maximum Users per NAT IP Address” is not reached. But if the number of chunks allocated is greater than or equal to the threshold limit of port-chunks, then the NAT IP address will not be chosen for a new subscriber. The remaining free port-chunks will be used for existing subscribers using the NAT IP address.
|
Whenever a NAT IP address is deallocated, all the port-chunks associated with the subscriber are released back to the pool.
|
l
|
In case of many-to-one not-on-demand NAT realms, the last port-chunk is not released back to the pool even after NAT Binding Timer expires. Only when the call gets disconnected, the port-chunk is released along with the NAT IP address.
|
|
l
|
In case of many-to-one on-demand NAT realms, when the last flow using the port-chunk gets cleared, the NAT Binding Timer is started. When the NAT Binding Timer expires, the port-chunk along with the NAT IP address is released back to the pool.
|
|
l
|
In case of one-to-one on-demand NAT realms, when there are no active flows using a NAT IP address, the NAT Binding Timer is started. When the NAT Binding Timer expires, the NAT IP address gets deallocated.
|
Subscribers sharing a NAT IP address are allocated NAT ports in chunks. The ports in a port-chunk are always used for the subscriber to whom that port-chunk is allocated irrespective of the protocol.
Whenever a NAT IP address gets allocated to a subscriber, the first port-chunk gets allocated along with the NAT IP address. Thus, for not-on-demand realms, the first port-chunk gets allocated during call setup, and for on-demand realms during data flow.
A subscriber’s data traffic is NATed with ports chosen in a random fashion from the port-chunk allocated to that subscriber. When all the ports in a port-chunk are in use, a free port-chunk is requested for. A new port-chunk is only allocated if the “Maximum Port-chunks Per User” is not reached.
When all flows using ports from a particular port-chunk get timed out/cleared, the port-chunk gets freed. When the last port of that port-chunk gets freed, the NAT Binding Timer starts counting. Before the NAT Binding Timer expires, if any new flows come up, ports are reallocated from the port-chunk, and the timer gets cancelled. The port-chunk cannot be deallocated as long as there are active flows using that port-chunk. But, if no new flows come and the NAT Binding Timer expires, the port-chunk gets deallocated.
In case of not-on-demand realms, the additional port-chunks that were allocated on demand will be deallocated based on the NAT binding timeout. However, the last port-chunk will not be deallocated even after the Binding Timer expires. This last port-chunk will only be deallocated when the NAT IP address is deallocated from the subscriber.
In case of on-demand realms, the port-chunks are deallocated based on the NAT binding timeout. When the last port-chunk gets freed, the NAT IP address also gets deallocated from the subscriber.
It is ensured that a port-chunk is associated with the subscriber as long as a valid NAT IP address is allocated to the subscriber.
When a subscriber disconnects, all port-chunks associated with that subscriber are freed. If the NAT Binding Timer has not expired, the port-chunks will not be usable immediately, only on NAT Binding Timer expiry will the port-chunks become available for new subscribers.
A global configuration option is available to indicate to the application by way of ICMP Error messages when a packet cannot be translated. Translation failures may be due to no NAT IP address or port being available for translation.
NAT does port management only for many-to-one realms. Hence, The TCP 2MSL timer is only available for many-to-one NAT. It is necessary to ensure that a TCP NAT port in Time Wait state is not reused if there are other free ports available for the subscriber. If such a reuse happens, then there is a possibility that connections might get terminated by the server. To avoid such issues, whenever a many-to-one NAT TCP flow gets cleared, the NAT port goes to Time Wait state (2MSL started for that port). Once 2MSL timer expires, the NAT port becomes usable. The 2MSL timer is started for every TCP NAT port as soon as the TCP connection gets cleared. This ensures that a NAT TCP port gets reused only after expiry of the configured TCP 2MSL timer.
Consider a case where a single TCP flow is active in a port-chunk. When this connection gets cleared, the TCP NAT port goes to Time Wait state. Since this is the last flow of the port-chunk, the NAT Binding Timer also gets started. Assume NAT Binding timer >= TCP 2MSL timer. Once the 2MSL timer expires, the TCP port becomes usable. However, the NAT Binding Timer keeps counting, and on expiry, the port-chunk is released.
In case the NAT Binding Timer < TCP 2MSL Timer, on NAT Binding Timer expiry, the TCP port is forcefully moved to Free State (made usable) from Time Wait state and the port-chunk released.
Whenever a NAT IP address or NAT port-chunk is allocated/deallocated to/from a subscriber, NAT Binding Records (NBR) can be generated. Generation of NBRs is configurable in the Firewall-and-NAT policy configuration.
NBRs are supported for both on-demand and not-on-demand NAT realms. For a one-to-one NAT realm, an NBR is generated whenever a NAT IP address is allocated/deallocated to/from a subscriber. For a many-to-one NAT realm, an NBR is generated when a port-chunk is allocated/deallocated to/from a subscriber for a NAT IP address. It is also possible to configure generation of NBRs only when a port-chunk is allocated, or deallocated, or in both cases.
The following is the list of attributes that can be present in NBRs. You can configure a subset of these attributes or all of them to be logged in NBRs. If an attribute is not available, while logging records that field is populated with NULL.
|
l
|
sn-nat-gmt-offset: Optional, GMT offset of the node generating this record. For example: -5.00, +5.30
|
Whenever a NAT IP address or NAT port-chunk is allocated/deallocated to/from a subscriber, to update NAT binding information for that subscriber in the AAA, a NAT Binding Update (NBU) can be sent to the AAA server.
Since port-chunk allocation/deallocation happens on a per-call basis, this ensures that AAA messaging is reduced to a great extent. NBUs are sent to the AAA server in accounting-interim messages. To send or not to send NBUs to the AAA server is configurable in the NAT realm configuration.
IMPORTANT: In this release, CoA query for NAT binding information is only supported for one-to-one NAT.If the NAT binding information is not available at the AAA, the AAA server can query the chassis for the information. This query uses the Change of Authorization (CoA) format, wherein the AAA sends a one-to-one NAT IP address as a query, and in the CoA query response the NBU is obtained if available at the time of query.
IMPORTANT: In StarOS 8.x, NAT for CDMA and early UMTS releases used rulebase-based configurations, whereas in later UMTS releases NAT used policy-based configurations. In StarOS 9.0, NAT for UMTS and CDMA releases both use policy-based configurations. For more information, please contact your local service representative.Firewall-and-NAT policies are configured in the Firewall-and-NAT Policy Configuration Mode. Each policy contains a set of access ruledefs with priorities and actions, and the NAT configurations. On a system, multiple such policies can be configured, however at any point of time only one policy is associated to a subscriber.
In a Firewall-and-NAT policy a maximum of three NAT realms can be configured. New realms cannot be added to a policy if the maximum allowed realms is already configured in it. However, a realm can be removed and then a new realm added. The realm that was removed will stay associated with the subscriber as long as the subscriber has active flows using that realm. If the subscriber is already associated with three realms, any new flows from that subscriber for the newly added realm will be dropped. A deleted realm is disassociated from the subscriber on termination of all flows from that subscriber using that realm. The new realm is associated with the subscriber only when the subscriber sends a packet to the newly added realm.
In the Firewall-and-NAT policy configuration, NAT policy must be enabled. Once NAT is enabled for a subscriber, the NAT IP address to be used is chosen from the NAT realms specified in matching access rule configured in the Firewall-and-NAT policy.
The Firewall-and-NAT policy used for a subscriber can be changed either from the command line interface, or through dynamic update of policy name in Diameter and RADIUS messages. In both the cases, NAT status on the active call remains unchanged.
|
l
|
ECS Rulebase: The default Firewall-and-NAT policy configured in the ECS rulebase has the least priority. If there is no policy configured in the APN/subscriber template, and/or no policy to use is received from the AAA/OCS, only then the default policy configured in the ECS rulebase is used.
|
|
l
|
APN/Subscriber Template: The Firewall-and-NAT policy configured in the APN/subscriber template overrides the default policy configured in the ECS rulebase. To use the default policy configured in the ECS rulebase, in the APN/subscriber configuration, the command to use the default rulebase policy must be configured.
|
|
l
|
AAA/OCS: The Firewall-and-NAT policy to be used can come from the AAA server or the OCS. If the policy comes from the AAA/OCS, it will override the policy configured in the APN/subscriber template and/or the ECS rulebase.
|
IMPORTANT: The Firewall-and-NAT policy received from the AAA and OCS have the same priority. Whichever comes latest, either from AAA/OCS, is applied.|
l
|
If the AAA/OCS sends the SN-Firewall-Policy AVP with the string “disable”, the locally configured Firewall-and-NAT policy does not get applied.
|
|
l
|
If the SN-Firewall-Policy AVP is received with the string “NULL”, the existing Firewall-and-NAT policy will continue.
|
|
l
|
If the SN-Firewall-Policy AVP is received with a name that is not configured locally, the subscriber session is terminated.
|
The Firewall-and-NAT policy can be updated mid-session provided the policy was enabled during call setup.
IMPORTANT: When the firewall AVP contains “disable” during mid-session firewall policy change, there will be no action taken as the Firewall-and-NAT policy cannot be disabled dynamically. The policy currently applied will continue.IMPORTANT: For all NAT-enabled subscribers, when the Firewall-and-NAT policy is deleted, the call is dropped.In a Firewall-and-NAT policy, you can change the NAT enabled/disabled status at any time. However, the updated NAT status will only be applied to new calls, active calls using that Firewall-and-NAT policy will remain unaffected.
A NAT realm can be selected based on the L3/L4 characteristics of a subscriber’s flows. NAT can be configured such that all subscriber traffic coming towards specific public IP address(es) always selects a specific NAT realm based on the L3/L4 traffic characteristics.
IMPORTANT: A maximum of three NAT realms can be configured in a Firewall-and-NAT policy. A subscriber can be allocated only one NAT IP address per realm. Hence, at anytime, there can only be a maximum of three NAT IP addresses allocated to a subscriber.This association is done with the help of access ruledefs configured in the Firewall-and-NAT policy. The NAT realm/NAT IP address to be used for a subscriber flow is decided during rule match. When packets match an access ruledef, NAT is applied using the NAT IP address allocated to the subscriber from the NAT realm configured in that access ruledef.
If no NAT realm name is configured in the access ruledef matching the packet, and if there is a NAT realm configured for “no ruledef matches”, a NAT IP address from the NAT realm configured for “no ruledef matches” is allocated to the flow.
If no NAT realm is configured for “no ruledef matches” and if there is a default NAT realm configured in the rulebase, a NAT IP address from this default NAT realm is allocated to the flow.
If a NAT realm is not configured in any of the above cases, no NAT will be performed for the flow. Or, if bypass NAT is configured in a matched access rule or for “no ruledef matches” then NAT will not be applied even if the default NAT realm is configured. The order of priority is:
When a new NAT realm is added to a Firewall-and-NAT policy, it is associated with the active subscriber (call) only if that call is associated with less than three NAT realms (maximum allowed). If the subscriber is already associated with three NAT realms, any new flows referring to the newly added NAT realm will get dropped. The newly added NAT realm is associated to a call only when one of the previously associated NAT realms is freed from the call.
Some network applications exchange IP/port information of the host endpoints as part of the packet payload. This information is used to create new flows, by server or client.
As part of NAT ALGs, the IP/port information is extracted from the payload, and the flows are allowed dynamically (through pinholes). IP and port translations are done accordingly. However, the sender application may not be aware of these translations since these are transparent, so they insert the private IP or port in the payload as usual.
For example, FTP NAT ALG interprets “PORT” and “PASV reply” messages, and NAT translates the same in the payload so that FTP happens transparently through NAT. This payload-level translation is handled by the NAT ALG module.
|
l
|
FTP: A TCP-based protocol that uses two flows, one for control messages and the other for data/file transfer. FTP uses PORT and PASSIVE reply commands to exchange data flow parameters. These commands carry the IP address and port information as part of payload.
|
|
l
|
RTSP: A TCP-based real-time streaming protocol having different methods to control real-time media transfer. The control messages have the port information embedded, which is used to transfer media.
|
To enable NAT ALGs, the routing rule(s) to the corresponding analyzers must be added to the rulebase.
sn-subscriber-nat-flow-ip: NAT IP addresses that are being used by NAT-enabled subscribers. The NAT IP addresses assigned from each of the associated realm for the call are logged. A space is used as a separator between IP addresses
NAT bulkstats are per context and per NAT realm. The NAT realms are configured in a context and statistics are stored per context per realm. These statistic variables, both cumulative and snapshot, are available in the nat-realm schema.
Bulkstats are only generated for the first 100 NAT realms from an alphabetical list of all NAT realms based on the context name and realm name. Therefore, to generate bulkstats for a specific NAT realm it must be named such that it gets selected in the first 100 bulkstats.
The following is the list of cumulative statistics that can be part of NAT bulkstats. The context name and the realm name are the two keys.
|
l
|
Total number of bytes transferred by realm: Cumulative bytes transferred through the NAT realm (sum of uplink and downlink).
|
|
l
|
|
l
|
Alert threshold values can be specified to generate alarms for NAT realms. To specify realm-specific threshold limits (pool-used, pool-free, pool-release, and pool-hold) “alert-threshold” NAT pool parameter can be used, or it can also be specified across context. These thresholds can be specified to any number of NAT realms.
In case of many-to-one NAT, it is possible to specify port-chunks usage threshold per NAT realm. This threshold value is applicable to all many-to-one NAT realms across the system. However, note that alarms are only generated for the first 100 many-to-one NAT realms from an alphabetical list of all NAT realms.
|
l
|
The public IP address used for the subscriber is recovered. The NAT IP address being used by the subscriber can be on-demand or not-on-demand. In case of many-to-one NAT, the port-chunks associated with the NAT IP address for the subscriber needs to check-pointed as well.
|
To recover the bypass NAT flow, the bypass flow needs to be checkpointed. The checkpointing of Bypass NAT flow can be:
In case of not-on-demand, the NAT IP address being used by the subscriber is known after call setup. This gets checkpointed as part of the normal full checkpoint. In case of on-demand NAT, the NAT IP address being used by the subscriber is known only in the data-path. This will be checkpointed as part of micro checkpoint.
In case of many-to-one NAT, the port-chunks being used will always be checkpointed as part of micro checkpoint.
Any information that is checkpointed as part of full checkpoint is always recovered. Data checkpointed through micro checkpoint cannot be guaranteed to be recovered. The timing of switchover plays a role for recovery of data done through micro checkpoint. If failover happens after micro checkpoint is completed, then the micro checkpointed data will get recovered. If failover happens during micro checkpoint, then the data recovered will be the one obtained from full checkpoint.
|
l
|
One-to-one NAT: Since NAT IP address being used for one-to-one NAT is recovered, on-going flows will be recovered as part of Firewall Flow Recovery algorithm as one-to-one NAT does not change the port.
|
|
l
|
Many-to-one NAT: On-going flows will not be recovered as the port numbers being used for flows across chassis peers/SessMgr peers are not preserved.
|
|
Cannot differentiate between ongoing traffic and unsolicited traffic.
A rule-match is done and if allowed, NAT will be applied accordingly on the packet.
|
||||
|
Unsolicited Traffic (downlink packets)
|
Cannot differentiate between ongoing traffic and unsolicited traffic.
Translation will be done and packet action taken based on the rule-match.
|
|||
|
Many-to-one NAT
|
||||
|
Ongoing Traffic
|
||||
|
If it is downlink packet, it will get dropped. If it is uplink, NAT will be applied with a new port.
|
||||
|
Unsolicited Traffic (downlink packets)
|
||||
|
Unsolicited Traffic (downlink packets)
|
||||
For more information, in the System Enhanced Feature Configuration Guide, see the Session Recovery and Interchassis Session Recovery chapters.
|
l
|
For many-to-one NAT, at least one valid NAT realm is configured in the Firewall-and-NAT policy, and that realm is configured in the context.
|
|
2
|
If all of the above is true, once a private IP address is allocated to the subscriber, the NAT resource to be used for the subscriber is determined. This is only applicable for not-on-demand allocation mode.
|
IMPORTANT: The private IP addresses assigned to subscribers must be from the following ranges for them to get translated:Class A 10.0.0.0 – 10.255.255.255
Class B 172.16.0.0 – 172.31.255.255
Class C 192.168.0.0 – 192.168.255.255
IMPORTANT: A maximum of three NAT realms can be configured in a rulebase. A subscriber can be allocated only one NAT IP address per NAT realm. Hence, at any point, there can be a maximum of three NAT IP addresses allocated to a subscriber.|
l
|
In case of one-to-one NAT mapping, the subscriber IP address is mapped to a public IP address. The private source ports do not change. The SessMgr installs a flow using the NAT IP address and a fixed port range (1–65535).
|
|
l
|
In case of many-to-one NAT mapping, a NAT IP address and a port from a port-chunk, are allocated for each connection originating from the subscriber. In order to identify a particular subscriber call line, the SessMgr installs a flow using NAT (public) IP address + range of NAT ports allocated for the subscriber.
|
The number of NAT ports to be allocated for each subscriber depends on the number of maximum associations allowed per subscriber. The number of NAT ports per subscriber must be lesser than or equal to any multiple of the number of max associations per subscriber. The number of associations per context/VPN and per subscriber is configurable.
NAT Processing continued...
NAT Processing continued...
NAT Processing continued...
